無服務(wù)器架構(gòu)是一種趨勢軟件設(shè)計(jì)模式，它消除了開發(fā)人員對服務(wù)器軟件和硬件管理的需求。在無服務(wù)器架構(gòu)中，也稱為無服務(wù)器計(jì)算或功能即服務(wù) (FaaS)，第三方服務(wù)（稱為后端即服務(wù)或“BaaS”）托管應(yīng)用程序。顧名思義，它并不真正涉及在沒有服務(wù)器的情況下運(yùn)行代碼。相反，擁有系統(tǒng)的人不需要購買、租用或配置服務(wù)器或虛擬機(jī)來運(yùn)行后端代碼。

AWS Lambda 是無服務(wù)器架構(gòu)的最佳示例，它實(shí)現(xiàn)了云計(jì)算的功能即服務(wù)模型。無服務(wù)器計(jì)算確保了理想的、預(yù)算友好的業(yè)務(wù)實(shí)施的可能性。無服務(wù)器應(yīng)用程序在由云提供商管理的無狀態(tài)計(jì)算容器中實(shí)現(xiàn)，這些容器是事件觸發(fā)的、短暫的（可能持續(xù)一次調(diào)用）。定價(jià)取決于執(zhí)行次數(shù)，而不是傳統(tǒng)架構(gòu)中的預(yù)購計(jì)算能力。功能即服務(wù)允許開發(fā)人員執(zhí)行代碼以響應(yīng)事件，從而消除了開發(fā)和維護(hù)基礎(chǔ)設(shè)施的復(fù)雜性。

使用 FaaS 編寫的無服務(wù)器代碼可以與以傳統(tǒng)服務(wù)器風(fēng)格編寫的代碼結(jié)合使用。FaaS 將應(yīng)用程序分解為功能和事件級別。Christos Matskas 為任何開發(fā)基于云的應(yīng)用程序的人提供了有用的總結(jié)。“Azure 為托管微服務(wù)提供了一個(gè)理想的平臺，因?yàn)樗峁┝嗽S多托管服務(wù)，允許開發(fā)人員創(chuàng)建可以可靠和大規(guī)模運(yùn)行的微服務(wù)。問題在于了解這些托管服務(wù)如何提供幫助以及哪種服務(wù)最適合該任務(wù)。”

無服務(wù)器 Java

可以使用 Java 構(gòu)建大型無服務(wù)器應(yīng)用程序。Java 方法在構(gòu)建各種可擴(kuò)展、可進(jìn)化和多 lambda 無服務(wù)器應(yīng)用程序方面非常有效。

實(shí)現(xiàn)無服務(wù)器功能

• 客戶端向無服務(wù)器計(jì)算平臺請求完成特定功能。
• 無服務(wù)器計(jì)算平臺最初會檢查該功能是否正在其任何服務(wù)器上運(yùn)行。如果沒有，平臺從數(shù)據(jù)存儲加載函數(shù)。
• 然后將該函數(shù)部署到其中一臺服務(wù)器上，并預(yù)先配置了一個(gè)執(zhí)行環(huán)境來運(yùn)行該函數(shù)。
• 執(zhí)行該函數(shù)以捕獲結(jié)果。
• 結(jié)果返回給客戶端。

無服務(wù)器架構(gòu)模式

Amazon Web Services的 Lambda 無服務(wù)器服務(wù)的五種主要使用模式包括：

1.事件驅(qū)動(dòng)數(shù)據(jù)處理

• 在事件之后觸發(fā)動(dòng)作，例如。觸發(fā) lambda 函數(shù)
• 非常適合混合趨勢
• 用于在更廣泛的托管環(huán)境中執(zhí)行請求的功能

2.網(wǎng)絡(luò)應(yīng)用

• 確定用戶上下文和個(gè)人元素的過程組合
• 靜態(tài)內(nèi)容用動(dòng)態(tài)內(nèi)容增強(qiáng)并存儲為動(dòng)態(tài)數(shù)據(jù)

3.移動(dòng)和物聯(lián)網(wǎng)應(yīng)用

• 服務(wù)于用戶上下文目的
• 檢查用戶是否被適當(dāng)授權(quán)
• 然后執(zhí)行功能，然后進(jìn)行數(shù)據(jù)交互以滿足用戶要求。

4.應(yīng)用生態(tài)

• 應(yīng)用程序工作流是在無服務(wù)器環(huán)境中開發(fā)的
• 實(shí)施后，向用戶發(fā)送反饋

5. 活動(dòng)工作流程

• 通過創(chuàng)建的決策樹的工作流分支操作

無服務(wù)器架構(gòu)的優(yōu)缺點(diǎn)

無服務(wù)器架構(gòu)的好處

1.降低運(yùn)營成本：作為一種外包解決方案，它為管理服務(wù)器、數(shù)據(jù)庫甚至應(yīng)用程序邏輯的支付鋪平了道路。成本削減來自兩個(gè)方面，基礎(chǔ)設(shè)施成本收益和勞動(dòng)力成本收益。您只需按執(zhí)行次數(shù)付費(fèi)。

2.更簡單的運(yùn)維管理：為Serverless架構(gòu)搭建各種環(huán)境非常簡單易行。它明確區(qū)分了基礎(chǔ)架構(gòu)服務(wù)和應(yīng)用程序。自動(dòng)擴(kuò)展功能降低了運(yùn)營管理開銷。無服務(wù)器系統(tǒng)不需要持續(xù)集成、持續(xù)交付或容器化工具。零系統(tǒng)管理是無服務(wù)器系統(tǒng)的另一個(gè)優(yōu)勢。

3.更快的創(chuàng)新：無服務(wù)器架構(gòu)消除了系統(tǒng)工程問題、更快創(chuàng)新和更新技術(shù)以獲得高效結(jié)果的可能性。

4.降低打包和部署的復(fù)雜性

無服務(wù)器架構(gòu)的缺點(diǎn)

1.第三方API問題：

• 安全問題
• 多租戶問題
• 供應(yīng)商控制
• 供應(yīng)商鎖定

由于 API 的實(shí)施而放棄系統(tǒng)控制也可能導(dǎo)致系統(tǒng)停機(jī)、功能減少、成本變化、意外限制和強(qiáng)制 API 升級。切換供應(yīng)商也是一個(gè)非常復(fù)雜的問題。許多 API 使您的無服務(wù)器系統(tǒng)容易受到攻擊，每個(gè) API 都會增加安全實(shí)現(xiàn)的數(shù)量。

2.缺乏操作工具：廠商負(fù)責(zé)提供調(diào)試和監(jiān)控工具。在無服務(wù)器架構(gòu)中，由于用戶請求由不透明的負(fù)載均衡器（如 AWS API 網(wǎng)關(guān)）處理，因此缺少訪問各種參數(shù)以確定根本原因的靈活性。

3.架構(gòu)復(fù)雜性：它們很復(fù)雜，需要很長時(shí)間才能構(gòu)建。評估、實(shí)施和測試以及決定功能應(yīng)該有多小需要花費(fèi)大量時(shí)間。必須在函數(shù)數(shù)量和應(yīng)用程序調(diào)用之間保持平衡。管理如此多的功能變得乏味，而忽略粒度會導(dǎo)致產(chǎn)生不必要的混亂。

4.網(wǎng)絡(luò)：無服務(wù)器功能只能通過私有 API 訪問。因此，您無法通過通常的 IP 訪問它們。

5.超時(shí)：由于 300 秒的超時(shí)限制與無服務(wù)器系統(tǒng)相關(guān)，過于復(fù)雜和耗時(shí)的功能不適合。由于這種限制，某些任務(wù)也被發(fā)現(xiàn)是不可能的。因此，無服務(wù)器系統(tǒng)對于執(zhí)行時(shí)間可變的應(yīng)用程序變得不可用。

如果系統(tǒng)真的需要無服務(wù)器架構(gòu)，則可以實(shí)現(xiàn)它。進(jìn)行詳細(xì)研究以了解它如何適合您的操作。無服務(wù)器系統(tǒng)仍處于初期階段，遵循無服務(wù)器系統(tǒng)的組織應(yīng)考慮過度依賴第三方 API 以及架構(gòu)復(fù)雜性的困難。